Controlling Symbols to Be Exported or Loaded

Controlling Symbols to Be Exported or Loaded

By default, to help avoid conflicts, symbols defined in an archive or a DSO that's used to build another DSO aren't externally visible. You can explicitly export or hide symbols with the -exported_symbol and -hidden_symbol options:

-exported_symbol name1, name2, name3

-hidden_symbol name4, name5

By default, if you explicitly export any symbols, all other symbols are hidden. If you both explicitly export and explicitly hide the same symbol on the link line, the first occurrence determines the behavior. You can also create a file of symbol names (delimited by white space) that you want explicitly exported or hidden, and then refer to the file on the link line with either the -exports_file or -hiddens_file option:

-exports_file yourFile

-hiddens_file anotherFile

These files can be used in addition to explicitly naming symbols on the link line.

Another useful option, -delay_load, prevents a library from being loaded until it's actually referenced. Suppose, for example, that your DSO contains several functions that are likely to be used in only a few instances. Furthermore, those functions rely on another library (archive or DSO). If you specify -delay_load for this other library when you build your DSO, the run-time linker loads that library only when those few functions that require it are used. Note that if you explicitly export any symbols defined in a library that the run-time linker is supposed to delay loading, the export behavior takes precedence and the library is automatically loaded at run time.

Delay-loaded shared objects do not function properly if direct references to data symbols exist in the delay-loaded object, or if the address of the function in the delay-loaded object is used. Therefore, only use -delay_load to load shared objects that have a purely functional interface.

Note: You can build DSOs using cc. However, if you want to export symbols/files or use -delay_load, use ld to build DSOs.